This chapter presents requirements and recommendations for PC Card 16 (previously referred to as PCMCIA cards) and CardBus under the Microsoft Windows family of operating systems.
Windows supports PC Card I/O cards. Memory PC Cards are only supported as legacy devices. For any PC Card device to work effectively with Windows, the manufacturer must implement a minimum set of tuples documented in the PC Card Standard. Windows uses these tuples to identify and configure any PC Card.
For PC 97, the new design concerns for PC Card are the following:
These new design details are discussed in this chapter.
Note Because CardBus implementations are just beginning, additional requirements might arise. As implementation details become available, Microsoft will provide information about revisions to the hardware requirements and recommendations at http://www.microsoft.com/hwdev/.
This section summarizes the basic standards for PC.
Required |
Designs for PC Card socket controllers, host controllers, and cards must all be based on the PCMCIA standards.
The February 1995 PC Card Standard adds requirements for minimum card information structure (CIS), 3.3v cards, multifunction cards, and cards that use DMA, and it introduces requirements for 32-bit PC Cards (CardBus). All PC Card devices must comply with these standards for PC 97.
This section summarizes PC Card requirements and standards for socket controllers.
Required |
The built-in PC Card 16 software in Windows includes drivers for the Industry-standard ExCA - compatible socket controllers. To be compatible with these drivers, socket controller implementations must support the Industry-standard ExCA base-register set. Notice that some controllers do not fully implement the base-register set and are incompatible. Also, some controllers implement extended registers or enhancements. The built-in Windows drivers do not exploit these features, even though the controller might be compatible.
Required |
The system design must maintain the mapping of the PC Card controller's IRQ Routing Register bits to system interrupt vectors. This means that when an interrupt is programmed in the controller to occur on the IRQx pin, the system's IRQ routing causes the interrupt controller to generate the interrupt vector for IRQx, and no other IRQ.
Required |
If the system supports CardBus, it must support the definition in "PCI to PCMCIA CardBus Bridge Register Description" ("Yenta" specification) for CardBus controllers (PCI-to-CardBus bridges). This definition includes a common PCI configuration space header assigned the Header Type field value of 82H. Although this is not yet incorporated into the PCI standard, Windows supports it. Any controller features that are not part of the "Yenta" specification will not be used in standard drivers. Any hardware-initialization or setup required to make the controller comply with "Yenta" or the other requirements listed here are the responsibility of the BIOS.
Because CardBus host controllers are PCI bus bridges, they will be supported (enumerated and configured) by the PCI software in Windows in the same manner as other PCI bus bridges. For information, see the "PCI" chapter in Part 3 of this guide.
Required |
The PC Card software will dynamically configure the bridge to utilize ISA interrupts for PC Card 16 cards, and use PCI interrupts for CardBus cards. Notice the requirement to "maintain mapping of IRQ routing" earlier in this section also applies to CardBus controllers. Also notice that systems implementing CardBus controllers must fully support PCI v. 2.1 and the additional PCI requirements for IRQ routing described in the "PCI" chapter in Part 3 of this guide.
Recommended |
CardBus host controllers are enumerated and configured in Windows 95, just as other PCI bus bridges. The PCI bus bridge support in Windows 95 is based on new requirements for PCI interrupt routing and bridge-window configuration. Because of this, full compliance with the latest PCI requirements is required for CardBus support.
For backward compatibility with Windows 95, there are steps the BIOS can take. Specifically, the BIOS must initialize the CardBus controller in Intel 82365-compatible mode and report it as device "PNP0E03, Intel 82365-compatible CardBus controller." Specifically, the requirements are as follows for BIOS POST time (CardBus controller ConfigSpace initialization):
This puts the CardBus controller into Legacy mode where Socketsv.vxd (the Windows 95 Socket Services driver) can access it as an Intel PCIC-compatible controller at an I/O address (for example, 0x3e0).
Notice that the BIOS must be at least PCI 2.1 compliant, meaning that it must at least support BIOS function (AX=0xb10e) GetIRQRouting and return the necessary PCI IRQ routing information, including the routing information for the CardBus controller. In general, if the CardBus controller is on the system board, there must be a slot routing entry for it in the table. If the CardBus controller is a PCI add-on card, there must be routing information entries for each PCI slot in the system.
During Plug and Play BIOS enumeration, the BIOS should report the CardBus controller as *pnp0e03 with a compatible ID of *pnp0e00 and the I/O resource of two ports (for example, 0x3e0 - 0x3e1). Windows 95 does not know about *pnp0e03, but it does know about *pnp0e00, so it will load Socketsv.vxd (for generic Intel PCIC-compatible controllers) and everything will work with the above BIOS initialization. The Windows 95 PCI enumerator (Pci.vxd) does not know about the CardBus controller's PCI header (Type 2), so it will not report the CardBus controller device at all.
In Windows 95, when the BIOS enumerator sees *pnp0e03, it will hide the device and call the BIOS to disable it. When the BIOS receives the disable call for *pnp0e03, it should do the following:
Required |
CardBus controllers are multifunction PCI devices, and Windows treats each function of a multifunction PCI device as an independent device. As such, there can be no sharing between functions of writable PCI Configuration Space bits (such as the Command register).
Notice that the PC Card 16-bit Interface Legacy Mode Base Address Register (offset 44h in the Type 2 PCI header) is the only exception to this requirement. This register must be shared between the two functions, as they must share the same registers for compatibility with the ExCA programming model.
Required |
For complete flexibility and support for typical configurations, CardBus controllers must support the independent location of R2 memory windows anywhere in the full system address space as recommended in the Industry-standard "Yenta" specification. Controllers that share a single page register among all R2 memory windows place the constraint on the system that all R2 memory windows must be located within the same 16-MB block. This is often not possible with typical DRAM (16 MB) and bridge (positive decode) configurations, and consequently will result in the disabling of cards in these cases.
This section summarizes the Plug and Play requirements for PC Card 16 cards.
The Windows operating system determines what type of card is plugged into the PC Card socket by examining the tuples on the card. For Plug and Play functionality, PC I/O cards must support a set of required information and configuration tuples. The PCMCIA bus enumerator uses these tuples to identify the card, load the correct device driver, and indicate all the possible configurations to the Plug and Play configuration manager. The configuration manager then dynamically assigns a valid configuration based on this information.
Required |
You must implement the following items for any PCMCIA I/O card that connects to a PC 97 system:
Windows uses the information contained in the required and recommended tuples to create a unique device identifier for the card and to assimilate configuration information for the device. Windows uses the device configuration tuples to determine the general characteristics of the card.
Required I/O Card Tuples
| ||
---|---|---|
Tuple identifier | Tuple code | Description and comments |
| ||
01h | CISTPL_DEVICE | Device information (common memory). For non-memory cards this tuple must be present, but the device type will be NULL. |
15h | CISTPL_VERS_1 | Level 1 version/product information: Product
information string |
1Ah | CISTPL_CONF | Configuration. Indicates the location of configuration registers and the registers present. |
1Bh | CISTPL_CE | Configuration table entry. Appropriate configuration requirements for I/O space, interrupts, memory, and so on should be specified. |
20h | CISTPL_MANFID | Manufacturer identifier. Card manufacturer identifier code. Defines manufacturer for this card. |
21h | CISTPL_FUNCID | Function identifier. Provides function information about the card. Also includes system initialization information. |
|
The device information tuple provides information about the memory devices used in the card's common memory space. The device type, size, and speed are used to configure the socket for efficient access to the card. This tuple must be present on PCMCIA I/O cards, but the device type must be NULL.
The Level 1 version/product information tuple contains human-readable information about the product and its manufacturer. This information is intended to be displayed to the user, where necessary. Windows uses the information contained in the product information and product name strings to construct the device identifier for that card. It also scans through the tuple, starting at the very beginning and going to the end of the product name string. The information gathered from the scan is one source for creating a 16-bit cyclic redundancy check (CRC) that Windows uses to construct the device identifier. Because the optional third and fourth strings in the tuple are not used in the CRC scan, devices that require unique numbers on each card can use these strings to store that information.
The configuration tuple tells the software where to locate the configuration registers that program the card's configuration, as well as which registers are present on the card.
Each configuration table entry tuple completely describes one valid configuration in which the card can operate. Each entry describes power, timing, I/O space, interrupt, and memory space requirements for the given configuration. Configuration software selects one of these configurations for the card based on the resources currently available in the system.
The manufacturer identifier tuple (CISTPL_MANFID, 20h) and the function identification tuple (CISTPL_FUNCID, 21h) add extra flexibility to a PC Card that connects to the PC:
Required |
Place the configuration entry tuples in the preferred order for configuring the device. Windows processes the tuples in the order they are placed in the card's information structure (CIS). From these tuples, Windows creates logical configuration in this order and prioritizes them in the same order. Notice that for multiple voltage cards the voltage policy is to prioritize 3.3V configurations (if supported by the system) over 5V configurations, regardless of the order of the configuration table entry tuples (CISTPL_CFTABLE_ENTRY).
Required |
Many older PC Cards specified "fixed" configurations to address compatibility with existing software. However, this is not the intended use for tuples; the configuration software should be responsible for compatibility. The tuples should be used only to rule out configurations not supported by the hardware. If you must provide fixed configurations for an operating system other than Windows, you must still provide one or more entries that specify the maximum configurability the hardware can handle.
This section summarizes the Plug and Play requirements for CardBus cards. CardBus was designed as a combination of PC Card 16 and PCI. The goal is to gain the benefits of PCI in the PC Card format. Consistent with this goal, Windows support for CardBus places specific requirements on CardBus cards.
Required |
The standard for CardBus defines a PCI-like configuration space that is not fully compliant with the PCI specification. Specifically, under the CardBus Standard, card vendors do not have to implement certain critical fields in the configuration space (described in the PC Card Standard as "allocated"). In the PC Card Standard Guidelines for silicon common to both PCI and CardBus products, the implementation of these fields is recommended.
However, to maintain compatibility with existing PCI system software and drivers for PC 97, Windows will support only CardBus cards whose configuration space is designed to meet the Common Silicon Guidelines.
This is required because CardBus configuration is performed by the PCI software, which knows how to deal with all aspects of PCI topology configuration, including bridging. Without the "allocated" fields, the cards cannot be treated fully as PCI devices and therefore cannot be supported under Windows.
The required "allocated" fields are listed in the following table.
Required "Allocated" Fields
| |
---|---|
Field | Description and comments |
| |
Vendor ID | This read-only field contains a Unique ID (in PCI space) for the manufacturer of the card. It is allocated by the PCI SIG. |
Device ID Revision ID | These read-only fields are vendor-assigned values that uniquely identify the device (among all vendors of PCI or CardBus products). |
Class Code | These read-only fields are defined in the PCI 2.1 specification. They describe what type of device this card is. |
Max_Lat Min_Gnt | These read-only fields specify the desired settings for Latency Timer values, according to the PCI 2.1 specification. Values of 0 indicate the device has no major requirements for the settings of Latency Timers. |
Interrupt Line | This register must be read-write and must not be connected to anything, just as on PCI cards. This register is used to store the current IRQ routing for the device. |
|
Required |
The CardBus specification also lists two fields as RESERVED (offset 2C in the configuration space), which have since been defined in the PCI v. 2.1 specification. These are also required on CardBus cards for Windows compatibility.
Required RESERVED Fields
| |
---|---|
Field | Description |
| |
SubSystem ID | If different from Device ID |
SubSystem Vendor ID | If different from Vendor ID |
|
Required |
For CardBus, Windows also requires the same set of card tuples as recommended in the PC Card Guidelines, as summarized in the following table.
Required Tuples for CardBus | ||
---|---|---|
Tuple identifier | Tuple code | Comments |
| ||
04h | CISTPL_CONFIG_CB | |
05h | CISTPL_CFTABLE_ENTRY_CB | |
07h | CISTPL_BAR | |
13h | CISTPL_LINKTARGET | Required as first tuple by PC Card Standard |
15h | CISTPL_VERS_1 | |
20h | CISTPL_MANFID | |
FFh | CISTPL_END | Required as end-of-chain tuple by PC Card Standard |
21h | CISTPL_FUNCID | Recommended in PC Card Standard; required for PC 97 |
|
Required |
CardBus controllers are multifunction PCI devices, and Windows treats each function of a multifunction PCI device as an independent device. As such, there can be no sharing between functions of writable PCI Configuration Space bits (such as the Command register).
For more information requirements related to the PCI Configuration Space, see the "PCI" chapter in Part 3 of this guide.
This section summarizes additional PC 97 Hardware Design Guidelines.
This section summarizes the specific power management requirements for PC Card. Power management requirements for specific device classes are defined in the related chapters in Part 4 of this guide.
Required |
The "Device Class Power Management Reference Specification" for the PC Card Controller Device Class provides class-specific definitions of the OnNow device power states (D0 - D3) for these devices. The specification also covers device functionality expected in each power state and the possible Wakeup event definitions for the class (for example, whether a card insertion should wake the system).
Required |
Any PCMCIA 5.0 card capable of signaling a Wakeup event to the system (as defined in the Device Class Power Management Reference Specification for its class) must implement the ReqAttn bit in the Extended Status register, its associated enable bit, and signaling on the #STSCHG line. PCMCIA 2.x cards must conform to the ExCA wakeup specification using but 4 of the Card Configuration and Status register to enable wakeup. Also, any card with a battery must support the Battery Voltage Detection (xBVDn) bits in the Pin Replacement register as currently defined in the PC Card Standard, and must support signal changes using the #STSCHG mechanism.
Required |
PCI-to-CardBus bridges and CardBus cards must conform to the requirements for power management on the PCI bus.
For information about PCI power management specifications, see the "PCI" chapter in Part 3 of this guide.
Required |
The PC Card Standard defines the requirements for ZV cards.
This section summarizes requirements for device drivers for PC Card.
Required |
The user must not be required to perform any action other than to insert disks that contain drivers and other files.
Required |
The user must not have to restart the system to be able to begin using the device, either after installation is complete or whenever the device is inserted in the system.
Required |
ZV-compatible PC Card drivers must use software interfaces based on 32-bit DirectDraw Live Video Extensions (LVE) to configure the graphics controller to receive video input using the ZV Port. This includes programming the graphics controller to configure the format of the video data, its location on screen, and so on. LVE is part of DirectX 3.0.
ZV card device drivers must handle dynamic graphics state changes, such as resolution changes, color depth changes, and switching to and from full-screen MSDOS - based applications.
This section lists some of the publications, services, and tools available to help build hardware that works with Windows operating systems.
PC Card support in Windows 95
http://www.microsoft.com/hwdev/busbios/
Windows 95 DDK
MSDN Professional membership
Microsoft diagnostic utility for PC Card
Microsoft provides a diagnostic utility that supports multiple
voltage cards,
MFC cards and the new Device ID mechanism. This
utility - Dtpl.exe - is
posted on the Microsoft FTP and web servers.
"Yenta" specification: PCI to PCMCIA CardBus Bridge Register Description
Published by Intel Corporation, available to all "Yenta"
members.
Phone: (800) 8794683
PCMCIA Standards
Personal Computer Memory Card International Association
2635 North First Street, Suite 209
San Jose, CA 95134 USA
Device Class Power Management Reference Specification
http://www.microsoft.com/hwdev/onnow.htm
PC Card Basic Requirements | ||
---|---|---|
1. All devices compliant with the PC Card Standard released February 1995 | ||
Required | ||
PC Card Socket Controllers | ||
2. Support the Industry-standard ExCA base-register set | ||
Required | ||
3. Maintain mapping of IRQ Routing Register bits to system interrupt vectors | ||
Required | ||
4. Support the industry-standard definition for CardBus bridges | ||
Required | ||
5. Support both ISA and PCI interrupts on CardBus controllers | ||
Required | ||
6. BIOS initializes CardBus controller in 82365-compatible mode and reports it as PNP0E03 for backward compatibility | ||
Recommended | ||
7. Writable PCI Configuration Space bits not shared by CardBus controllers | ||
Required | ||
8. Each R2 memory window in CardBus controller has it own page register | ||
Required | ||
Plug and Play Design for PC Card 16 | ||
9. Required I/O card tuples supported | ||
Required | ||
10. Configuration entry tuples listed in priority order | ||
Required | ||
11. Maximum configuration options specified | ||
Required | ||
Plug and Play Design for CardBus | ||
12. Configuration space meets the Common Silicon Guidelines | ||
Required | ||
13. RESERVED fields compliant with PCI v. 2.1 | ||
Required | ||
14. CardBus required and recommended tuples implemented | ||
Required | ||
15. Writable PCI Configuration Space bits not shared by CardBus controllers | ||
Required | ||
PC 97 Requirements for PC Card | ||
Power Management for PC Card | ||
16. Compliance with "Device Class Power Management Reference Specification" for PC Card controller | ||
Required | ||
17. PC Card 16 cards implement power-related events using the ReqAttn bit and the #STSCHG mechanism | ||
Required | ||
18. CardBus controllers and cards implement PCI power management specifications | ||
Required | ||
19. ZV-compatible PC Cards compliant with the PC Card standard definitions for Zoomed Video | ||
Required | ||
Device Drivers and Installation for PC Card | ||
20. No user intervention required for correctly installing devices | ||
Required | ||
21. Device functional immediately without restarting the system | ||
Required | ||
22. ZV-compatible PC Card driver uses DirectDraw Live Video Extensions | ||
Required | ||
|